Subject: Modified APPN Architecture items

From: "Ralph Case" <[email-masked]>
Date: Thu, 6 Jul 95 14:00:03 EDT

Ref:  note from [email-masked] to [email-masked]
      Mon, 19 Jun 1995 15:32:06 -0400

No comments have been received by the July 3 date.

Verifying Session Reachability when Performing Topology Nonverify
  The requested changes have been made in the subject document and
  no comments have been received.  I read a consensus that this is
  approved.

Detecting Duplicate CP names when one Node is a VRN
  The concerns have been addressed and no comments have been received.
  I read a consensus that this is approved.

New NOF Command to Allow Network Nodes to Ignore COS Supplied by Client Nodes
  This proposal does not address all of the concerns raised at the SIG
  meeting, but it does stand on its own, and it does provide a specific
  function that there is a need for.  I take this as a consensus that this be
  approved and the related concerns about other restrictions remain
  open for discussion.  OK?

Ralph Case                    [email-masked]    (919)254-1882
APPN/APPC Architecture
IBM Networking Hardware Division

---

From: Howard Blevins <[email-masked]>
Date: Thu, 6 Jul 1995 11:13:18 -0700 (PDT)

Ralph,
  We did send comments. They were sent on the 30th of June. I have
  enclosed the original email that I sent to Tim.

Howard Blevins
3Com Corp.

>From heb Fri Jun 30 16:21:19 1995
From: Howard Blevins <[email-masked]>
Subject: Modified APPN Architecture items (fwd)
To: [email-masked]
Date: Fri, 30 Jun 1995 16:21:15 -0700 (PDT)
Cc: [email-masked] (Howard Blevins)
Content-Length: 3583      
Status: RO

Tim,
  Here are some comments from the 3Com folks. Sorry they are kind of
  late.

Howard Blevins
3Com Corp
(408) 764-6985

Comments for all three documents:

1) Are they optional or manditory?
2) What version of APPN will they be apart of?

arch8264 Comments:
1) For Figure 8-14 NN(OLU) Search logic, we felt that the changes you
made were not necessary. When you search the directory database, if
the resource is "not found" or is known to be a NN, then check the topology
database. If the resource is found (i.e it is a NN) then you are done. It
was not clear why you added the "search that node" leg of off the
"check topology database"
2) Page 8-82, QUERY_CPNAME(RSP), origin endpoint TG vectors may or may not
3) Page 8-83, QUERY_CPNAME(RQ), "If DS finds a destination NAU is not
in its domain (i.e. ...) or cannot find the destination NAU" Should really be 
"If DS cannot find the destination NAU".

arch8265 Comments:
1) Where is the format for CPDB006? We assume it will be added to the
MS Arch Ref.
2) On page 7-34, 3rd paragraph, the sense code for the DEACTIVATE_CP_CP_SESSION
needs to be specified. We assume you meant to use 0x081d005; however, that
is not clear in the document.

arch8266 Comments:
1) In general, this command does not do what we would like it to do. We
normally know the nodes we trust and don't know the ones that we don't
trust. It would be better if we could specify the node that we are not
going to restrict. For this reason, we feel it would be better to modify
the define_adjacent_node command and break down the authorization level
into two parts: authorized to establish CP-CP sessions and authorized
to do mode to cos mapping. We would need to add a command that determines
the default value for unknown nodes.
2) This command also seems to conflict with the current define_adjacent_node
command. What if a node is authorized and "all" has been specified
in define_client_node_restriction? If you stay with the
concept of define_client_node_restriction, then it has to be documented
on how it works with define_adjacent_node.

Forwarded message:
> From [email-masked] Mon Jun 19 12:32:57 1995
> Date: Mon, 19 Jun 1995 15:32:23 -0400
> Message-Id: <[email-masked]>
> Errors-To: [email-masked]
> Reply-To: [email-masked]
> Originator: [email-masked]
> Sender: [email-masked]
> Precedence: bulk
> From: [email-masked]
> To: [email-masked]
> Subject: Modified APPN Architecture items
> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
> X-Comment:  APPN Reference
> 
> The change pages for three modifications to the architecture have been placed
> on the Networking file server.  The three modifications were presented as
> proposals at the last AIW APPN reference SIG meeting.  Modifications
> suggested by members at that meeting have been incorporated in the
> documents.  Members (i.e. you guys and gals) have until Monday, July 3rd to
> review the documents, at which time, I'll be requesting CP status approval from
> you.
> 
> The change pages are located under directory aiw/appn/architecture.
> 
>    arch8264.psbin   Verifying Session Reachability when Performing Topology
>                        Nonverify
>    arch8265.psbin   Detecting Duplicate CP names when one Node is a VRN
>    arch8266.psbin   New NOF Command to Allow Network Nodes to Ignore COS
>                        Supplied by Client Nodes
> 
> Regards and Happy Reviewing,
> Tim
> 
>

---

From: Dave Finnie <[email-masked]>
Date: Fri, 7 Jul 1995 08:19:47 +1000

Howard,

>   enclosed the original email that I sent to Tim.

I'm pretty sure I didn't see them on this mail exploder, and the mail
header you included seems to show that you sent them *only* to Tim.

I think the whole idea of the AIW and these mail exploders is that we
can all discuss these issues as a group. Signoff of these items
requires us to all agree (or have concensus :-)), so we should all
have a think about any issues that you might have to raise.

> 2) What version of APPN will they be apart of?

Good point. We covered these at the AIW, but it would be a good idea
to include them in the doco.

> "check topology database"

I think the idea is that it is possible that we may have lost a route
to the NN. In fact, the NN may have disconnected completely, and come
back up as an EN, etc. So it is necessary to check with TRS that our
cached entry (in DS) is still valid.

> 2) Page 8-82, QUERY_CPNAME(RSP), origin endpoint TG vectors may or may not

Not sure what this means. Missing line(s) ?

> "If DS cannot find the destination NAU".

Agree.

Dave

---

From: Howard Blevins <[email-masked]>
Date: Thu, 6 Jul 1995 15:35:44 -0700 (PDT)

Dave,
  I meant to send the original email to the exploder but I think I had
  4 day weekend on my mind. Sorry about that.

  A line did get truncated and I did want to clarify my comment.

  For arch8264 on page 8.82, QUERY_CPNAME(RSP) it says "If DS provided
  a COS and origin endpoint TG vectors on ...". My comment was that
  endpoint TG vectors may or may not be present. They won't be present
  if the locate came from a local LU in a NN. In this case, TRS should
  still return an RSCV. 

Howard

---

From: Dave Finnie <[email-masked]>
Date: Fri, 7 Jul 1995 10:30:21 +1000

Howard,

>  4 day weekend on my mind. Sorry about that.

No such luxury for us here down under ! :-) Hope the fireworks were
good.

>  if the locate came from a local LU in a NN. In this case, TRS should

Good point. So is only depends on whether COS is supplied as to
whether an RSCV is returned. Is that what you meant ?

Dave

---

From: Howard Blevins <[email-masked]>
Date: Thu, 6 Jul 1995 17:22:52 -0700 (PDT)

> whether an RSCV is returned. Is that what you meant ?

Yes!